[レポート] DNSの夏後半戦！ DNS Summer Day 2019に参加してきました（午後の部） #dnsops

日本DNSオペレーターズグループ (DNSOPS.JP) 主催の DNS Summer Day が今年も開催されました。この記事では午後に行われたパネルディスカッションならびに 6 セッションについてレポートします。

#レポート

#DNS

渡辺聖剛

2019.06.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

6/28 に行われた DNS Summer Day 2019 に参加しましたのでレポートします。前半（午前中）のセッションについては下の別記事をご覧ください。

[レポート] 今年もDNSの夏！ DNS Summer Day 2019に参加しにきました（午前の部） #dnsops 【更新中】

午前・午後と通してながめてみると、今年はやはりドメインハイジャックがトピックスだったのかなと思えます。昨年あれだけ騒がれた DNS ブロッキングは単体の話題にはならないものの、セキュリティやプライバシーを語る上でキーワード的にでてきており、議論のベースになった感じがあります。

なお、例年資料は後日公開されていました。その時にはこの記事もアップデートいたします。

レジストリロックに学ぶ実在性証明

※パネルディスカッション形式のセッション

スピーカー情報

コーディネータ
- 山本功司日本DNSオペレーターズグループ
パネリスト
- 大泰司章一般財団法人日本情報経済社会推進協会（JIPDEC）
  - 実在性証明に関しての専門家
  - 専門家というか実務を扱っている
- 大久保智史 digicert
  - 認証局やレジストリ実務の専門家

資料（物理）

2015年に作成された資料の抜粋が配布されました。

内容

「ドメイン名」は誰のものか？
所有者が意図しないところでドメイン名が移転される
そもそも「誰」がそのドメイン名を取得できるのか、属性型JPドメインなど
- 誰 = 実在性の証明
この 1 年の間でそういう事件が多かった
- アタックじゃなくてもドメンハイジャックができてしまう（しまった）
- 有名な某ドメインが取られてしまった、大学合併によるドロップキャッチ　など

実在性証明について（大泰司氏より）

JIPDEC
- 個人情報保護の推進、インターネット上の情報の信頼性確保
信頼性（トラスト）
- 電子契約・電子署名
- Webサイト　常時SSL、脆弱性診断改ざん診断
- eメール　S/MIME, SPF, DKIM, DMARC, 安心マーク, PPAP禁止
なりすまし対策の調査
- （レジストリロックやDNSSECは調査できるものか？ -> できる、と会場から）
書面の場合
- 実在性
  - 登記事項証明書
  - （登記されたまま動いていない法人も。。。）<- 税務署が把握
- 本当にその法人によって成された行為か
  - 書面＋押印＋印鑑証明書（＋委任状）
電子データの場合
- 実在性
  - 商業・法人登記のオンライン申請（有料PDF）
  - 国税庁法人番号公表サイト（無料で検索可能、APIあり）
- 本当にその法人によって成された行為か
  - 電子ファイル＋電子署名＋電子証明書（＋電子委任状）
    - 参考 : 法務省：電子署名法の概要と認定制度について
  - アカウント＋認証
    - 各サイトばらばら
    - （法人共通認証基盤？）
    - （経済産業省(METI)にて実証実験中）-> 民間でも使えるよう要望中
サイバー法人台帳ROBINS
- 法人の実在性と各種情報を検索できるサイト
- 確認者、現地調査＋対面
  - コスト：大
  - 確認者 = その会社の顧問であることが多い
JCAN証明書
- 法人等内の個人、組織、ものに対して発行される電子証明書
- 申込書＋本人確認資料＋在籍証明書
  - コスト：中（ROBINSよりは低い
標準企業コード cci-kcode
- EDIで使われる
- 国税庁法人番号公表サイト or ROBINS
  - 法人番号がない場合・個人の場合は国税庁けだと無理
- 申込書＋メール＋郵便（＋電話）
  - コスト：小
OSIオブジェクト識別子
- 組織を特定する番号、認証局や医療機器などで
- 登記事項証明書
- 申込書＋メール＋郵便（＋電話）
  - コスト：小

トーク1

「会社の登記事項証明書は誰でも取れるのか？」-> 本セッションのキモ
印影の信頼性（3Dプリンタのある時代に。。。？）
- この件に限った話ではない
（実際問題として）印鑑登録証明書が必要ない属性JPドメインがある
- 設置法で存在証明される
「コストを下げるには、どこかが証明したものを使い回すようにする」
一生懸命がんばれば確認することもできる
レジストリロックなどの確認について、実務上のところを大久保さんに

大久保氏より

議論がやっと始まった段階
レジストリロックの有効無効
- そもそもなんでやってるの？レジストラロックでいいのでは？
レジストリロック
- レジストラがコントロールしても同じ
- じゃあ何故？
ICANNコミュニティで「今後どうするか」の議論
本来はレジストリが登録者に確認するのがいい
- いまはレジストリは情報を持たない -> 確認できない
- レジストラが代行 -> 電話をかけてくる
- 電話がなんとかなればok...?

トーク2

どういう技術をつかって確認を行うべきか？
大泰司氏
- 電子署名 or 認証
- エンド登録者とDBを持っている一の間で
- いろんな業者がいると社会のコストが増えていく
大久保氏
- 第3社をいれる。レジストリとレジストラの間で仲介する
- レジストラを介さずにレジストリロックのON/OFFを
- USではそういう提案をしている
共通化して社会インフラ化されるのが望ましい
会場から
- JPRSより：レジストリロックというサービスの意義
  - 指定事業者の手続きに承認を与える、その先に指定事業者が登録者識別をかぶせて実行すると強固になる
  - 何を持って確認しているか、というところは公開しない契約になっている（のでしない
  - 偽造できるのでは、というところについては、そもそも犯罪であるという抑止力
- レジストリロックについては日本独特の解釈になっている

スポンサーセッション1: XACK DNS開発とRFC

スピーカー情報

松原豊和
- 株式会社XACK

内容

XACK DNS Zone Editor
- XACK
XACK DNS
- 製品紹介｜XACK DNS | XACK
- フルスクラッチ
- BIND互換、DNS Manager(GUI)
DNS開発する上でRFC大事
- 一部解釈に困った
1. 差分ゾーン転送 RFC1995
- SOA要求がここには書いてない。。。
- RFC1034に書いてあった
- ポイント : あるひとつの機能を記述するのに必要な情報が複数にまたがっている
1. 空の非終端（Empty Non-Terminal
- 明示的にこの記述がかいてない
- RFC5155で若干、8020で明記
- ポイント : あとのRFCで明記されるまで曖昧なものがある
3.1. TTL関連ゾーンファイル
- 2181にTTLの最小値と最大値の記述あり、超過時の応答内容も -> XACKで準拠して実装
- BINDの実装は拡大解釈っぽい
- 非互換性のせいで移行の時に困った -> XACKで許容するオプションを用意した
3.2. TTL関連 SOA MINIMUM
- RFC2308で再定義
- ポイント : 実装によって解釈が異なる
3.3. TTL関連 RRSIG
- ポイント : エラーケースなどの記述が網羅されていない
1. NSEC->NSEC3への移行・戻し
- RFCに書いてある手順が実際問題として全パターン実行できない
- ポイント : 具体的な手順がわからない
まとめ
- RFC準拠は必要不可欠
- 解釈違いの調整も必要
- 準拠しない対向先への考慮も必要

国産BINDオルタナとしてのエンタープライズ向けDNSとして名高いXACK DNSですが、それ故に開発は苦労も多いようです。。

スポンサーセッション2: OX PowerDNS - A Faster, Safer and More Secure Internet

スピーカー情報

Jan Hilberath
- Open-Xchange

内容

OX : Open-Xchange
PowerDNS
- バックエンドにDB
- 2002年にOSS、最近はセキュリティ・プライバシーにフォーカス
プロダクト
- OX PowerDNS Recursor
- OX PowerDNS Authoritative Server
  - ZoneControl WebGUI(有償)
- OX PowerDNS DNSdist
- OX PowerDNS Protect システムソリューション
  - マルウェア対策、ペアレンタルコントロール
  - ブロッキングとか（海外では使われている、むしろ法律で必要と決まっている）
5G による要求
- DNSサーバのレイテンシ - 東京大阪の二ヶ所程度では遅い
有償版
- Monitoring & Notification
  - OSSでもメトリクスはとれる
  - 有償版なら詳細グラフィカルなダッシュボード付き
- サポート、メンテナンス
- ヘルスチェック

スポンサーセッション3: DNSデータを使用したサイバー脅威やボットの検出

スピーカー情報

渡辺アラン
- PIPELINE株式会社

内容

PIPELINE
- 脅威インテリジェンスデータを収集している
- The Spamhaus Projectのアジア地区
脅威TOP10の悪意のある国のうち 8割がアジア
- フィッシング
- マルウェア
- DGA(Domain Generate Algorithm)
- クリプトジャッキング
- C2 (command and COntrol)
グローバルのBot状況
- 2017年 800万件 -> 2019年すでに1,300万件
  - TOP10は8割アジア
日本国内
- 2017年 9万 -> 2019年 12万
- 海外と日本国内でグロースパターンが似ている
- 2019年のボットネットドメイン
  - 1位が amazon.com
  - 2017年は ISP がほとんどだった
RPZ
- DNS Response Policy Zones
- DNSで多くの悪意のある活動を検出する
- DNSのデータをタグ付け(リアルタイムに驚異判定)、ログ解析

今年国内で検知された Botのうち 1/4 以上が Amazon.com ドメイン、つまり AWS というデータを公開されていました。AWS は EC2 から外部への怪しいふるまいを監視し abuse として細かく報告するということを行っていますので、個人的に集計方法や定義が気になります。詳細情報が確認でき次第アップデートしたいと思います。

スポンサーセッション4: DNS界のできごと（2018年7月～2019年6月） - JPRSが発信した技術情報から -

スピーカー情報

森下泰宏
- 株式会社日本レジストリサービス（JPRS）

内容

JPRSの技術情報発信
- Web
- 電子メール、メルマガ
- SNS
- ひと(対面)、ブース出店
発信内容
- 脆弱性情報の公開(21件)
  - BIND以外が13件
- ルートゾーンKSKロールオーバー
- DNS Flag Day
- ほか
脆弱性情報
- BIND
  - 昨年は6件、今年すでに6件
  - 1件、事前情報公開から一般公開に時間がかかったケースあり
  - BIND脆弱性予報士の予報が外れたことがあった
  - LTができなくなったひともいた
- Knot Resolver
  - キャッシュポイズニングがわりと簡単にできてしまう脆弱性
ルートゾーンKSKロールオーバー
DNS flag day
- 公式「とてもうまく行ったイベントだった」
  - （まだこれから影響がでてくるイベントかもしれない）
DNSがよくわかる教科書株式会社日本レジストリサービス(JPRS) 渡邉結衣、佐藤新太、藤原和典
- 重版出来、まもなく3刷

ISPから見たDoT/DoHの話

スピーカー情報

Nickolay Boyadjiev
- 株式会社コミュニティネットワークセンター (CNCI)

内容

ブルガリアのccTLD
- ブラジルに似ているということでICANNに2回くらい却下された
- ドメイン数は二桁程度
Encripted DNS
DNS over TLS
- RFC7858
- 853/tcp (udpはDNS over DTLS)
- systemd が opptunistic DoTに対応
  - opptunistic (日和見) = まず DoT でリゾルブを試みて、ダメであれば通常の DNS クエリにフォールバックする手法
DoH
- Web系人間（Mozilla, Cloudflare, Google）が超高速標準化
- WGできて2年でRFC
- RFC8427
- cloudflared
- Firefoxで使うのは簡単
  - チェックボックスをONにするだけ
  - DoHサーバへのアクセスがIPv6にならない？ -> 何回かやってたらなった
- DoHが使うDNSサーバはブラウザの設定
  - オペレータがコントロール出来ない
集中型DoHは何故気にする必要がある？
- シェア50%以上のブラウザがやろうとしているから
ISPから見た場合
- DNS通信が見えなくなるのでサポート対応できなくなる
  - お客さんに「Cloudflareのせいですね」って言っても伝わらない
  - 自分たちのせいにされる
- サービスレベル低下の恐れ
  - 障害起きても何もわからない
- フィルタリング
  - 児童ポルノブロッキングができなくなる
  - 海外に「通信の秘密」はない
- ネットワーク経路設計が狂ってしまう（主にCDN）
  - 想定していないところからトラフィックが増えたりすることになる
    - GeoIPの判定ミス
  - バランスが崩れる、コスト増の恐れ
- ユーザセキュリティレベルの低下
- メリットを感じない
- 自社ユーザがだまされるのが気に入らない
一般的な課題
- エンプラネットワークへの影響
- プライバシー保護の有効性が怪しい
- DNSセキュリティ対策として不完全
- プロバイダ集中（DNS over Cloud)
  - 攻撃しやすくなる、スケールが難しい、「分散インターネット」の概念に反している
  - ROOT改ざんの可能性、ネット中立性
- 更なるプライバシー侵害
- セキュリティ研究への影響
  - Passive DNSが使えなくなり分析が難しく
- Bot
  - C&C over DoH（PoCあり
Q&A
- DoT/DoHをIIJがやることに葛藤はある
  - さすがIIJさんだなぁと思ってみていた
- 上げてもらった問題のうち、パブリックDNSサービスを使うとどうなるか、という側面もある。問題点をカテゴリに分けて整理するとよさそう
  - おっしゃるとおり

EDNS Client Subnet（ECS）

スピーカー情報

松本陽一
- アカマイ・テクノロジーズ合同会社

内容

エンドユーザーマッピング
権威サーバで、送信元のIPアドレスをチェックし、最適なサーバーのIPアドレスを返す
うまくいく条件
- いまのところよく動いていた
- パブリックDNSなどでうまく行かないところもでてきた（IP Anycastでも限界あり）
ECS - フルリゾルバから権威サーバへのクエリに、佐伯要求も翌ライアンとのIPアドレスのサブネット情報をつける
- OPT 疑似 RR を追加セクション内に定義
- OPTは他の一般的なRRとは異なるフォーマット
- OPT自体はECSのためだけのものではない
dig で確認可能 +subnet
- 比較的新しいものでないと機能が無いかも
ECSの利用
- みんなが対応することを目指すものではない
- フルリゾルバ側
  - 付けたいときのみ権威ネームサーバ宛てのクエリに付ける
    - ホワイトリスト
- 権威
  - 対応したくなければECSは無視する
  - 送信元IPアドレスやECSに基づいて異なるIPアドレスを返すこと自体が各々独自
  - 虚偽のアドレスを付けるクライアントは信頼したくない
    - ホワイトリスト
- 権威とフルリゾルバの合意・調整が必要
- 公開DNSでは原則としてECSを付けるものもある
ECSを複雑にしてしまうもの
- 権威はソースと異なるスコープを返しても良い
- フルリゾルバへのクエリにクライアントがECSを付けても良い
- クライアントがつけたECSをフルリゾルバは無視してもいいし拒否してもいい
- サブネットが細かいほど
  - キャッシュが太る
  - キャッシュミスが増える
- 将来ECSを利用することを考えると、ネットワーク内のIPアドレスの割り当てにおいて、ネットワークトポロジーや地理的位置をなるべく短いプレフィクスに反映させるのがよいかもしれない
ECS以外のアプローチ
- 従来型
IPv6とマッピング、ECS
プライバシー
- 通常権威はクライアントの情報が見えない -> プライバシーの後退では無いか？
- /32じゃなくてサブネットで送信する（アグリゲーションすることでキャッシュ効率を上げる意味もあるが）
- オプトアウトも可能
- MozillaのTrusted Recursive Resolverポリシー